String() is designed to make it easy to compare coomputed plan vs expectations

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

- Remove the `convergence` struct and `newConvergence` constructor
- Extract `resolveServiceReferences` as a standalone function taking
  `map[string]Containers` instead of a method on convergence
- Add `getContainersByService` helper on composeService
- Update run.go and executor.go to use the new standalone function
- Remove dead code: `getObservedState`, `setObservedState`

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

…remove

- Fix ContainerReplaceLabel detection: use op.Inherited != nil (not
  op.Container) as signal for recreate in execCreateContainer
- Use observed network name (not desired) for DisconnectNetwork and
  RemoveNetwork operations, in case the name changed
- Use observed volume name (not desired) for RemoveVolume operations
- Update reconciliation.md with 3 new lessons learned (7.8, 7.9, 7.10)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

ensureProjectVolumes already prompts the user when a volume's config hash
diverges from the compose file (create.go:1626) and recreates it on confirm.
The reconciler ran after ensureProjectVolumes and prompted again with the
exact same message — so a user who declined the first prompt was asked the
same question a second time.

Drop the prompt + recreate call from reconcileVolumes(). Recreation of
diverged volumes stays owned by ensureProjectVolumes; the reconciler only
plans the creation of missing volumes. If the user declined recreation,
the existing container's mounts still match the existing volume name and
hasVolumeMismatch correctly returns false, so containers are not falsely
flagged as obsolete.

Keep the supporting infrastructure available for future use, when
divergence detection migrates fully into the reconciler:

  - reconciler.prompt field
  - prompt parameter on reconcile()
  - planRecreateVolume function (//nolint:unused)
  - servicesUsingVolume function (//nolint:unused)
  - noPrompt test helper

The reframed test (TestReconcileVolumes_DivergedIsIgnored) asserts the
new contract: a diverged volume produces no plan operations from the
reconciler.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>

Two related changes to the executor, plus the small cleanups they
attracted in review:

* Rename node consults a planner-set CreateNodeID instead of walking
  ancestors. The old execRenameContainer searched node.DependsOn for a
  CreateContainer result and fell back to a recursive walk through the
  group chain. That worked only by convention; a future op with cross-
  node data needs would have to rediscover or copy the pattern. Now the
  rename op carries an explicit CreateNodeID int set at plan time and
  the executor reads pctx[CreateNodeID].ContainerID directly. The
  recursive findCreatedIDInChain is gone.

* Stop re-listing containers on every create. execCreateContainer used
  to call getContainersByService(ctx, projectName) — a fresh
  ContainerList per create — to resolve service references at execute
  time. The executor now holds a live containersByService view seeded
  from ObservedState (via observed.containersByService()) and grown as
  OpCreateContainer nodes complete, so service references resolve from
  memory. On OpRemoveContainer the removed container is dropped from
  the view via slices.DeleteFunc, so a dependent's create that resolves
  network_mode: service:x against the just-removed container cannot
  pick up a stale ID (Containers.sorted() orders by canonical name and
  would otherwise return the removed container).

* Defensive slices.Clone of op.Service.VolumesFrom in execCreateContainer.
  resolveServiceReferences mutates VolumesFrom in place, and the
  shallow struct copy of *op.Service still shares the backing array.
  Single-execution-per-node makes it safe today, but the clone removes
  the trap for any future parallel-execution mode.

* Operation gains a CreateNodeID int (not a *PlanNode pointer) to avoid
  a structural cycle between Operation and PlanNode. OperationType
  values are pinned to explicit integers so adding an op in the middle
  cannot silently shift the others.

* execRenameContainer carries two checks so a missing CreateNodeID and
  an empty produced ID are distinguishable in logs. Both are programmer
  invariants (prefixed "internal:").

* containersByServiceFromObserved moved from a package-level helper to
  a method on *ObservedState.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>

Three improvements identified in the Principal Engineer pass but
deliberately deferred:

1. Test fidelity. Split executePlan into newPlanExecutor (constructs
   the executor seeded from observed state) and (*planExecutor).run
   (walks the DAG). Production callers go through executePlan
   unchanged. TestExecutePlanRemoveContainerDropsFromCache now uses
   newPlanExecutor + run, exercising the same errgroup, done-channel
   and group-tracker wiring as production instead of a hand-rolled
   loop over executeNode.

2. //nolint:unused chain. The three preserved helpers
   (reconciler.prompt, planRecreateVolume, servicesUsingVolume) each
   carried a separate "kept for future" comment. Consolidate the
   rationale on the reconciler.prompt field doc and point the helper
   nolint directives there, so a future cleanup is a single grep.

3. Concurrency test. Add TestExecutePlanConcurrentRemovesCacheCoherence
   which builds N independent Stop→Remove chains in one plan; the
   errgroup fans them out across goroutines that all hit
   containersByService under the mutex. Passes under -race. Failure
   would expose a missing or incorrect lock.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>

executor.go had grown to ~480 lines mixing three concerns:

  - DAG orchestration (run, executeNode, planExecutor struct)
  - per-OpType implementations (execCreateNetwork, …, execRenameContainer)
  - event tracking (groupTracker + per-OpType emit helpers)

Split into three files of ~170 lines each, one concern per file:

  - executor.go        — planExecutor, reconciliationContext, run, executeNode dispatch
  - executor_ops.go    — all execXxx methods
  - executor_events.go — groupTracker + emitStartEvent / emitDoneEvent / emitErrorEvent

Pure refactor: no functional change. Tests (incl. -race) and lint both pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>

Two coverage gaps surfaced by an external review:

- TestReconcileContainers_DependsOnChain: asserts that a service B with
  depends_on: [A] produces a CreateContainer for B that depends on A's
  last plan node (the serviceNodes mechanism in infrastructureDeps).
  This was the only depends_on-via-plan-DAG behavior untested before.

- TestReconcileContainers_DependsOnScaleDown: companion test that
  exercises the scale-down → dependent path specifically, verifying
  that the previous commit's lastNode-on-scale-down fix actually wires
  the dependency through.

- TestOperationTypeString: adds OpRunProvider to the table; all other
  OperationType values were already covered.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>